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Technical Field 

The present invention relates generally to spacecraft simulation, 
and more particularly, to a spacecraft simulation system that allows multiple 
ground station ranging. 

5 Background Art 

The increasing complexity and cost of various spacecraft and 
associated launch and ground systems therefore have created a need for 
extensive detailed validation and verification before deployment along with 
rigorous training for support personnel fi-om booster separation to satellite end 

10 of life. Examples of systems contributing to the need for extensive testing and 
training include: (i) multiprocessor-based systems which can have complex 
software architectures; (ii) multiple laimch systems with various delivery 
characteristics and mission requirements; (iii) multiple ranging systems used to 
support mission and on-going operations; (iv) groimd systems with multiple 

15 interacting elements; and (v) sophisticated ground software for automated 
spacecraft operations. 

However, system-level ground testing to verify fixU system 
performance of a spacecraft and associated systems as well as a realistic training 
environment for support personnel can be costly and/or inadequate. Present 
20 implementations of hardware-in-the-loop systems to provide ground testing 
require special purpose interface hardware, software and hamessing to create a 
test environment whereby system hardware or emulations thereof can be 
integrated with high-fidelity, real-time simulations and then instrumented to 
facilitate testing and training. 
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As the spacecraft orbits the earth multiple ground stations are 
used to provide ranging vectors that provide real time information such as range, 
azimuth and elevation data of the spacecraft. As the satellite moves around the 
earth different groimd stations and thus different ranging and tracking systems 
can monitor the spacecraft and generate ranging, azimuth and elevation data. 
The fimctions of the ranging and tracking systems are particularly important 
when the spacecraft is first launched into a transfer orbit and precise position 
data is required to efficiently and safely move the satellite from the transfer orbit 
into its final orbit. Then too, during normal operations, efficient station keeping 
is dependent upon the precise knowledge of spacecraft position. Turnaround 
ranging is typically used whereby two or more ground stations are used to 
improve the determination of spacecraft position. Thus, there is a need to 
simulate the operation of various ranging and antenna systems at various times 
to provide a complete simulation of the system. Prior efforts for simulating 
different ground stations include using different simulators for each of the 
ranging and antenna systems throughout the world that are to be used for a 
specific mission. However, such an approach is extremely costly due to the 
great number of simulators required. Also, systems that implement a separate 
machine to represent each ground station ranging mechanism require a complex 
exchange of ephemeris or ranging information with corresponding complexities 
related to time tagging of information. Inaccuracies of only a few milliseconds 
in these systems will result in invalid ranging results and comprise testing 
results. Another type of system modifies internal geographic references on a 
scheduled basis to match the ranging and tracking schedule in the ground 
control software. Sharing scheduling information creates considerable 
complexity and substantial modifications to the ground station software that 
then propagates to the simulation system. Limitations of the system may 
compromise the flexibility of the operational ground system design. 



It would therefore be desirable to provide a single simulation 
system that allows multiple ground stations to be simulated accurately with 
respect to time. 

Summary of the Invention 

It is an object of the invention to provide a low cost, high fidelity 
system for time critical testing of a spacecraft and associated ground systems. 

It is a further object of the invention to provide a simulation 
system that provides relative spacecraft data from multiple user-selectable 
ground sites. 

In one aspect of the invention, a spacecraft emulation system for 
emulating the operation of a spacecraft and the operation of a plurality of 
ground stations is coupled to a spacecraft status and control system that requests 
a connection to one of the plurality of simulated ground stations. Range and 
tracking data is calculated for each of the plurality of simulated ground stations. 
Ranging and tracking servers are instantiated by client(s) contained within the 
status and control system in order to retrieve specified ground station range and 
tracking data in accordance with instantiation parameters. The ranging and 
tracking servers then provide the requested range and tracking data to the status 
and control clients. 

Further, the present invention provides a method for simulating 
the operation of a spacecraft comprising the steps of: 

requesting a connection to one of a plurality of simulated ground 

stations; 

generating a range server name; 




in response to the range server name, generating server location 



parameters; 



' calculating range data for each of the plurality of simulated 
ground stations; and, 

providing the range data for one of the plurality of simulated 
groimd stations. 

Embodiments of the present invention are advantageous in that 
the system may be used beyond a ranging and tracking application. That is, the 
simulation system may use one platform to simulate multiple systems in a less 
expensive and less complex manner. 

These and other aspects and embodiments of the present 
invention will become better understood with regard to the following 
description, dependent claims and accompanying drawings. 

Brief Description of the Drawings 

Figure 1 is a block diagrammatic view of an embodiment of a 
real-time spacecraft simulation system in accordance with the preferred 
embodiment of the present invention; and 

Figure 2 is a data flow diagram of a real-time spacecraft 
simulation system in accordance with the preferred embodiment of the present 
invention. 

Best Modes For Carrying Out The Invention 

FIG. 1 is a block diagram of a real-time spacecraft simulation 
system 10 in accordance with the present invention. The real-time spacecraft 
simulation system 10 can be embodied by an Applied Dynamics Real Time 
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Station (AD RTS) 11 manufactured by Applied Dynamics. The AD RTS 11 
system is a stand-alone VMEbus-based real-time simulation and analysis system 
that uses a mixture of 9U x 400 mm ADI or commercial off the shelf (COTS) 
processor and input/output cards. Physically, the AD RTS system can be 
5 contained in a mini-tower housing 1 1 . 

The real-time spacecraft simulation system 10 includes one or 
more simulation engines (SE) 12, 13 which are used to simulate system 
dynamics in real time. For an AD RTS system 11, the simulation engines 12, 13 
are in the form of processor cards installed therein. 

10 Each simulation engine 12, 13 is a single board computer (SBC) 

that solves dynamic equations of motion, power or heat transfer in real-time. 
One or more simulation engines can be installed in the real-time spacecraft 
simulation system as problem size and complexity increase throughput 
requirements. In the preferred embodiment, the first simulation engine 12 hosts 

15 the simulation software that allows it to be used to model the dynamics 
associated with the attitude control subsystem (ACS) of the spacecraft. The 
ACS simulation engine 12 models dynamics, sensors and actuators along with 
environmental and orbital conditions. The orbital simulation determines the 
spacecraft position and in addition, the range, altitude and azimuth relative to 

20 several ground station locations. In a constructed embodiment, the simulation 
engine 12, was implemented in a MVME2604 SBC operating at 330 MHz. 

In the preferred embodiment, the simulation engine 13 hosts the 
simulation software that allows it to be used to model non-ACS spacecraft 
subsystems, such as power, thermal, propulsion, and payload (power and 
25 thermal characteristics). In a preferred embodiment, the simulation engine 13 is 
implemented in a MVME2604 SBC. However, the simulation engine may be 



• 
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embodied in a variety of other forms. The simulation modules 12, 13 are also 
preferably implemented in an ADI proprietary simulation language such as 
ADSIM. 

A host computer 14 with an interface 14A is utilized for 
5 simulation development, cross-compiling, interfacing to a user, and displaying 
output information. The host computer 14 can be embodied by a computer 
E;3 workstation such as ones available from Sim, Hewlett-Packard, or VAX, for 

example. The host computer 14 runs simulation system software havmg 

?i: interactive commands which provide simulation control and status. The 

111 

C^3 10 simulation system software can be embodied by ADI SlMsystem software. 

\ii 

jn Interface 14A provides the proper protocol to commimicate with AD RTS 11. 

fx The host computer 14 through interface 14A commimicates with 

a VMEbus interactive manager (VIM) 16 through an Ethernet line or other 
tj communication line 15. The VIM 16 is operative to initialize and control the 

15 real-time spacecraft simulation system 10, download application software to the 
embedded processors in the real-time spacecraft simulation system 10, and 
monitor simulation parameters in real-time. The VIM 16 is also operative to 
provide servers that simulate the TCP/IP servers of the ground station baseband 
unit (BBU) and antenna control unit (ACU). The VIM 16 resident servers 

20 provide bi-directional data transfer between the processors in the real-time 
spacecraft simulation system 10 and the ground segment spacecraft status and 
control system clients (46) via an Ethemet 15 connection; spacecraft telemetry, 
ranging and tracking data in one direction and spacecraft or unit command data 
in the other direction. The VIM 16 also contains software that supports the 

25 SlMsystem operating system. In a preferred embodiment, VIM 16 was 
constructed of a Motorola MVME2604 SBC with a Unix based operating 
system. 



The VIM 16 through the VMEbus 18 communicates telemetry 
and command data to the ECTCU 43 via the second simulation engine 13 which 
may contain interfacing software logic. The ECTCU 43 which is the 1553 
databus bus controller, is a functional equivalent of the Central Telemetry and 
Command Unit (CTCU) bus controller element of the spacecraft. It contains 
non-flight versions of the CTCU flight components along with a customized 
version of the PROM sequencer firmware. 

The ESCP 40 of the AD RTS system is a VMEbus-compatible 
card that emulates a Spacecraft Control Processor (SCP). The ESCP 40 includes 
a microprocessor along with supporting circuitry to execute flight software. The 
ESCP 40 and the simulation engines 12, 13 are accessed to perform data 
transfers, and to provide/receive data to/from the VIM 16 for real-time data 
logging and user control. A plurality of ESCPs can be included to reflect the 
redxmdancy of operational systems. 

The 1553 RT card 34 is used to imitate the various MIL STD 
1553 remote terminals (RT) used on a 1553 databus 36 that correspond to MIL 
STD 1553 RTs on the spacecraft. Specifically, the 1553 RT card 34 imitates the 
hardware interface of respective bus and payload Remote Telemetry and 
Command Units (RTCUs), as well as, the Hemispherical Inertial Reference 
Unit. The 1553 RT card 34 is preferably a commercial card from SBS. The 
software logic controlling the 1553 RT card 34 may physically reside in the 
second simulation engine 13 and may be implemented in C or COSIM, which is 
another proprietary language from ADI. The 1553 RT card 34 is preferably 
coupled to the 1553 databus 36, an ECTCU bus controller 43, and an ESCP 40. 



8 

The VMEbus 18 is utilized for time, command, telemetry, 
ranging, tracking, sensor, and actuator interfacing. Actuator data is 
communicated from the ESCP 40 to the simulation engine 12 via the VMEbus 
18. Sensor data is communicated from the simulation engine 12 to the ESCP 40 
via the VMEbus 18. Telemetry data is communicated from the ESCP 40 to the 
host computer 14 and/or ground segment spacecraft status and control system 
clients (46) via the VEM 16 and the VMEbus 18. Command data is 
communicated from the host computer 14 and/or ground segment spacecraft 
status and control system clients (46) to the ESCP 24 via the VMEbus 1 8 and 
the VIM 16. Ranging and tracking data is communicated from the simulation 
engine 12 to the host computer 14 and/or ground segment spacecraft status and 
control system clients (46) via the VIM 16 and the VMEbus 18. 

Telemetry, ranging and tracking data transferred to the ground 
segment spacecraft status and control system clients (46) must be accurately 
time-tagged with a minimal amount of time domain drift and bias. To obtain a 
highly accurate time source, in order to control time domain drift and bias 
throughout the simulation system 10, a device such as a stratum one server 50 
and a time code translator 52 may be used within system 11. The server 50 may 
be coupled to communication line 15. The stratum one server acquires 
Universal Time from the GPS satellite constellation and thereby provides a time 
reference via a network time protocol (NTP) or with an TRIG time code signal. 
In a preferred embodiment, the IRIG data is transferred to a time code translator 
52 via a dedicated interface 51. The time code translator 52 then makes 
Universal Time data available to the VIM 16, and simulation engines 12,13 via 
the VMEbus 18. 

VIM 16, as mentioned above, is preferably a UNIX-based system 
that may be programmed to provide a variety of functions. As was discussed 
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above, various satellite simulation data may be generated. The satellite 
simulation infomiation as will be further described below^ may include various 
range and tracking data for ground stations supported by the system. 

A ground segment spacecraft status and control system (46) 
containing multiple TCP/IP clients may also be coupled to system 11. The 
status and control system clients (46) request simulation data from various 
groimd station servers by establishing data connections, with groimd station 
specific servers uniquely identified by IP address and port number. Ground 
station servers typically have common port numbers assigned to specific server 
types. For instance, a ranging server will have the same port number regardless 
of the ground station it is contained within. Nevertheless, ground segment 
spacecraft status and control systems typically allow for operator programming 
of both the IP address and port number although, typically the port number for a 
particular server type (e.g. telemetry, command, ranging, tracking) remains 
constant from ground station to ground station. 

Referring now to Figure 2, spacecraft status and control system 
clients 46 are illustrated coupled to system 1 1 . System 1 1 includes an interface 
48 coupled to a ranging server 50 and tracking server 52. Ranging server 50 and 
tracking server 52 are coupled to satellite simulation 54 which represents the 
data from satellite simulation engines 12 and 13. In addition, satellite 
simulation 54 may generate range data illustrated as 56 and tracking (attitude 
and elevation) data represented by 58. Interface 48 may also be coupled to 
INETD configuration store 60 and services store 62. 

As mentioned above, the system 1 1 is preferably a UNIX-based 
computer system. Interface 48 is preferably a TCP/IP socket interface and 
INETD daemon process found in UNIX-based systems. The interface 48 
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receives a connection request from a spacecraft status and control client 46 
identifying a specific port address for the particular ground station service 
(server) desired to be accessed. The spacecraft status and control clients utilize 
a common LP address but unique port address for a specific service. 
(Conversely, an operational system utilizes a imique IP address and common 
port address). That is, the system 11 identifies the different groimd station 
information with different port numbers. Upon the request from the spacecraft 
status and control client 46, the ranging server name corresponding to the port 
address is received from the services store (file) 62. The interface 48 then uses 
the server name to retrieve the server application location and operating 
parameters from the INETD configuration store (file) 60. The INETD deamon 
process then instantiates the server process and passes the operating parameters 
to it as illustrated in figure 2 whereby the interface 48 is coupled to ranging 
server 50 and tracking server 52. A data connection between the status and 
control client 47 and a specific server is therefore established as illustrated in 
figure 2 whereby the ranging server 50 is coupled to the status and control 
ranging client 47 and the tracking server is coupled to the status and control 
antenna control unit client. The Satellite Simulation 54 repeatedly updates the 
determination of the spacecraft range, attitude and elevation for a multiple of 
ground stations. By virtue of the operating parameters a specific instance of a 
ranging or tracking server obtains ranging or tracking data for a specific groimd 
station and transfers the time-tagged data to the status and control client 47 as 
requested. In the preferred embodiment, both range data and antenna data are 
provided. However, the antenna control unit could be omitted from a system. 

In operation, a connection to one of a plurality of ground stations 
is requested. The desired range server name is generated and in response to the 
range server name, the server location parameters are also obtained. Range data 



4 



11 

is continually calculated for each of the plurality of simulated ground stations 
supported by the system and the range server provides range data for the 
plurality of simulated ground stations. Likewise, the desired tracking server 
name is generated and in response to the tracking server name, the server 
5 location parameters are also obtained. Tracking data (spacecraft elevation and 
azimuth) is continually calculated for each of the plurality of simulated ground 
stations supported by the system and the tracking server provides azimuth and 
elevation data for the plurality of simulated groimd stations. 

While the best modes for carrying out the invention have been 
10 described in detail, those familiar with the art to which this invention relates 
will recognize various alternative designs and embodiments for practicing the 
invention as defined by the following claims. 



